Skip to main content

EVPN Part 4: Routing Giữa Các VNI & Multi-Homing

Loạt EVPN (7 phần): 1. Vì sao cần EVPN & Fabric · 2. MAC VRF & IP VRF · 3. Route Types & MAC/IP · 4. Inter-VNI & Multi-Homing · 5. Cấu hình & Troubleshooting · 6. Routing Table nội bộ · 7. Multi-Site RT & Route Leak (sắp đăng)

Phần 4/7 trong loạt EVPN: đọc sau Phần 3: Route Types & Cách Học MAC/IP. Phần này đi sâu vào Type 5, hai mô hình routing giữa các VNI (Asymmetric/Symmetric IRB), multi-homing bằng ESI, rồi khép lại bằng việc kéo dài một VLAN qua nhiều site.

Ở Phần 2, Mục 3, mô hình Symmetric IRB đã được đi qua theo từng bước của một gói tin hoàn chỉnh. Phần này đặt mô hình đó cạnh mô hình còn lại (Asymmetric IRB) để thấy rõ vì sao ngành đã chọn Symmetric làm mặc định, đồng thời trả lời một câu hỏi còn treo lơ lửng: nếu một server cần nối tới hai leaf cùng lúc để tránh single-point-of-failure, EVPN xử lý việc đó thế nào? Đó là chủ đề của multi-homing/ESI ở Mục 3.

Ba câu hỏi cốt lõi mà phần này trả lời, cũng là ba câu hỏi khép lại toàn bộ mảng "khái niệm" của loạt bài trước khi Phần 5 trở lại với CLI thật:

  1. Type 5 (đã lướt qua ở Phần 3) hoạt động chi tiết ra sao, và trường GW IP trong route đó quyết định điều gì (Mục 1)?
  2. Giữa hai mô hình routing liên-VNI (Asymmetric và Symmetric IRB), sự đánh đổi cụ thể là gì, và vì sao gần như mọi triển khai hiện đại chọn Symmetric (Mục 2)?
  3. ESI, khái niệm đã xuất hiện thoáng qua ở Type 1 (Phần 3), thực chất định nghĩa thế nào, nó giải quyết bài toán gì khi một server cần nối tới nhiều leaf cùng lúc, và vì sao chính nó lại là nền để kéo dài một VLAN qua nhiều site (Mục 3, 4)?

Mục lục​

1. Type 5 — IP Prefix Route (Chi tiết)​

Phần 3 đã giới thiệu Type 5 ở mức tổng quan: nó quảng bá cả một subnet (/24, /16...) thay vì một host /32 như Type 2. Một chi tiết dễ nhớ nhầm: Type 5 không nằm trong chuẩn EVPN gốc. RFC 7432 chỉ định nghĩa Type 1–4; Type 5 được chuẩn hóa riêng và muộn hơn, ở RFC 9136 (2021), chính vì nhu cầu tách bạch việc quảng bá IP prefix ra khỏi route MAC/IP.

Cấu trúc route và trường GW IP​

Type 5 route mang các trường: Route Distinguisher, IP Prefix (subnet cần quảng bá), GW IP (Gateway IP, giải thích ngay dưới đây), L3 VNI (VNI để đóng gói traffic), và Route Target.

Trường GW IP là phần dễ gây nhầm lẫn nhất, vì hành vi của nó phụ thuộc vào một cấu hình gọi là advertise direct-nexthop (sẽ thấy trong CLI thật ở phần sau):

  • Không có advertise direct-nexthop: GW IP đóng vai trò một Overlay Index, tức một địa chỉ IP trung gian mà leaf nhận route phải tra tiếp qua một Type 2 route khớp đúng IP đó mới suy ra được VTEP đích (gọi là recursive resolution, vì phải "route" qua route). Địa chỉ này thường là một IRB/gateway nằm ngay trong fabric, nhưng với DCI thì có thể là router bên ngoài. Trong hay ngoài fabric không phải chi tiết cần nhớ ở đây. Chi tiết cần nhớ là GW IP tự nó không đủ để forward: leaf luôn phải tra thêm một bước nữa.
  • Có advertise direct-nexthop (cách làm này còn gọi là Pure Type 5): GW IP bắt buộc là 0.0.0.0, không phải "IP của chính VTEP" như đôi khi bị hiểu nhầm. Thay vào đó, route mang kèm một thuộc tính riêng gọi là router's MAC extended community (đi cùng next-hop BGP chính là VTEP gốc phát ra route), nên leaf nhận route đã đủ thông tin để gửi thẳng VXLAN tới VTEP đó, không cần recursive resolution qua Type 2 nào cả. Cách này đơn giản hơn và phổ biến hơn trong một data center thuần EVPN.

Type 5 /24 vs Type 2 /32 — ai thắng khi trùng match?​

Hai loại route có thể tồn tại đồng thời cho cùng một dải địa chỉ, nên phải biết cái nào được ưu tiên. Nguyên tắc longest-prefix-match truyền thống vẫn áp dụng: Type 2 luôn cụ thể hơn (đúng một địa chỉ /32), còn Type 5 chỉ là một subnet tổng quát (/24). Nếu một leaf nhận cả 10.1.1.10/32 (qua Type 2) lẫn 10.1.1.0/24 (qua Type 5), lookup cho 10.1.1.10 sẽ match Type 2 (dài hơn, cụ thể hơn); lookup cho một IP khác trong cùng subnet như 10.1.1.99 (chưa có Type 2 host route riêng) sẽ rơi vào Type 5.

Type 5 And Type 2 Overlap Without ConflictType 2 host route10.1.1.10/32Type 5 prefix route10.1.1.0/24Route lookuplongest prefix winsDestination 10.1.1.10matches the /32, Type 2 winsDestination 10.1.1.99no host route, falls back to /24Both routes coexist happily: the classic longest-prefix-match rule settles every lookup

Type 5 dùng cho DCI (Datacenter Interconnect)​

Khi hai data-center riêng biệt (DC-1 với subnet 10.1.0.0/16, DC-2 với 10.2.0.0/16) cần thông nhau qua WAN, mỗi Border Leaf (leaf biên, có kết nối ra ngoài fabric) học route từ WAN qua eBGP thông thường, rồi quảng bá lại vào EVPN fabric dưới dạng Type 5. Các leaf nội bộ nhận Type 5 này, biết "muốn đến 10.2.0.0/16 thì gửi VXLAN tới Border Leaf", và Border Leaf sẽ forward tiếp ra WAN.

Type 5 for DCI (Datacenter Interconnect)DC-1 (10.1.0.0/16)Leaf-IntBorder LeafBorder Leaf receives Type-5:10.2.0.0/16 via WAN (eBGP)re-advertises it into the EVPN fabricLeaf-Int learns this routesends VXLAN to the Border Leafwhenever it needs 10.2.0.0/16DC-2 (10.2.0.0/16)Border LeafLeaf-IntWAN / DCI linkEach Border Leaf is both the door into the EVPN fabric and the door out to the WAN

2. Inter-VXLAN Routing — Asymmetric vs Symmetric IRB​

Phần 2, Mục 3 đã trình bày chi tiết Symmetric IRB qua một luồng gói tin cụ thể. Mục này đặt nó cạnh mô hình còn lại (Asymmetric IRB) để thấy rõ sự đánh đổi giữa hai lựa chọn. Cả hai đều thuộc IRB (Integrated Routing and Bridging: tích hợp routing và bridging vào một cơ chế duy nhất), được chuẩn hóa chính thức ở RFC 9135.

Bài toán chung của cả hai mô hình: VM-A ở VNI 1000 (10.1.1.0/24) muốn nói chuyện với VM-X ở VNI 2000 (10.2.2.0/24). Hai bên khác subnet, nên chắc chắn cần định tuyến (routing) qua một gateway.

Model 1: Asymmetric IRB (đi cùng Anycast Gateway toàn diện)​

Trong Asymmetric IRB, mọi leaf đều có SVI/IRB cho tất cả VNI, không riêng VNI mà nó đang host cục bộ. Nghĩa là Leaf1 có cả irb.1000 lẫn irb.2000, dù có thể không có VM nào của VNI 2000 nằm trên Leaf1.

Asymmetric IRB — Routing Happens at Ingress LeafLeaf1: holds irb.1000 AND irb.2000VM-A (VNI1000)① routes LOCALLY on Leaf1 (irb.2000 is here)② Encap with target VNI 2000 (L2 VNI)Leaf2③ VNI=2000, so onlybridging is left, no second routeForwards straight to VM-XDownside: Leaf1 must keep MAC entries for ALL VNIs, even those with no local VM

Đường đi của gói VM-A gửi cho VM-X (ở Leaf2, VNI 2000): Leaf1 nhận packet tại irb.1000, nơi có địa chỉ Anycast MAC giống hệt trên mọi leaf. Vì Leaf1 cũng có irb.2000 cục bộ, nó route ngay tại chỗ, ngay tại leaf tiếp nhận. Chữ "asymmetric" nói về đúng chi tiết này: việc lookup diễn ra bất đối xứng, chỉ ở một phía.

Sau khi route xong, Leaf1 tra bảng EVPN để biết MAC của VM-X nằm ở VTEP nào, rồi đóng gói VXLAN với VNI đích chính là Layer 2 VNI của VNI 2000, không phải một VNI L3 riêng. Leaf2 nhận gói và chỉ cần bridge thuần túy layer 2, không phải route lại.

Ưu điểm: đơn giản, không cần Layer 3 VNI riêng. Nhược điểm: mỗi leaf phải lưu MAC table cho toàn bộ VM trong toàn bộ VNI, kể cả VNI nó không host VM nào, nên không mở rộng tốt khi số lượng VNI lên tới hàng nghìn.

Model 2: Symmetric IRB (dùng L3 VNI riêng) — mô hình đã học ở Phần 2​

Khác với Asymmetric, ở Symmetric IRB mỗi leaf chỉ có IRB cho đúng những VNI nó host cục bộ. Leaf1 chỉ có irb.1000 và không có irb.2000, nên khi cần route sang VNI 2000 thì nó không tự route local được nữa. Đó là lý do phải có một Layer 3 VNI riêng (đã học ở Phần 2): Leaf1 dùng route Type 5 (10.2.2.0/24 tại VTEP của Leaf2, L3 VNI 50000) để biết gửi gói tới đâu, rồi đóng gói với VNI = Layer 3 VNI thay cho L2 VNI đích.

Leaf2 khi nhận sẽ route lại một lần nữa trong VRF của nó, trước khi bridge ra irb.2000 tới VM-X. Chữ "symmetric" nằm ở đây: cả hai đầu, ingress leaf lẫn egress leaf, đều làm một bước route giống nhau, đối xứng.

Symmetric IRB: One Route Lookup At Each EndLeaf-1 (ingress)lookup 1 in the IP VRFencap with the L3 VNILeaf-2 (egress)lookup 2 in the IP VRFthen bridge to irb.2000VM-AVNI 1000VM-XVNI 2000VXLAN, VNI = L3 VNI 50000no L2 VNI of the destination appears in the headerBoth ends do the same work, and that symmetry is why each leaf only needs MAC entries for its own VMs

Ưu điểm: mỗi leaf chỉ cần MAC table cho VM cục bộ, nên mở rộng tốt hơn nhiều. Nhược điểm: phức tạp hơn, cần cấu hình Layer 3 VNI riêng cho mỗi VRF tenant.

So sánh trực diện hai mô hình​

Asymmetric IRBSymmetric IRB
IRB trên mỗi leafTất cả VNI (Anycast GW toàn diện)Chỉ VNI cục bộ
Routing diễn ra ởIngress leaf (một lần)Cả ingress lẫn egress leaf (hai lần)
VNI dùng trong tunnelL2 VNI đíchL3 VNI (VRF VNI)
MAC table cần lưuToàn bộ VM từ xaChỉ VM cục bộ
Khả năng mở rộngKém hơnTốt hơn
Phổ biến ởData center nhỏ/vừaData center lớn

Trong thực tế triển khai hiện đại (kể cả trên Junos, sẽ thấy ở phần sau), Symmetric IRB gần như luôn là lựa chọn mặc định, vì lợi thế về khả năng mở rộng thường quan trọng hơn độ đơn giản của Asymmetric.

3. EVPN Multi-Homing (ESI)​

Phần 3, Mục 3 đã dùng ESI xuyên suốt phần giải thích Type 1 (fast convergence, aliasing, split horizon) nhưng luôn hẹn "sẽ định nghĩa kỹ hơn ở Phần 4". Mục này trả lời cái hẹn đó: quay lại từ đầu bài toán mà ESI giải quyết, trước khi ráp nó vào đúng những cơ chế Type 1 đã dùng.

Vấn đề cần giải quyết: một điểm lỗi duy nhất (SPOF)​

Nếu một server chỉ nối tới đúng một leaf, leaf đó (hoặc link nối tới nó) chết là server mất mạng hoàn toàn: một single point of failure kinh điển. Giải pháp tự nhiên là nối server tới hai leaf khác nhau cùng lúc. Nhưng làm vậy lại đặt ra một câu hỏi mới: hai leaf đó phối hợp với nhau thế nào để không gửi trùng lặp traffic và không tạo loop? Trả lời được câu đó là việc của multi-homing, với ESI làm công cụ trung tâm.

ESI là gì?​

ESI (Ethernet Segment Identifier) là một định danh 10 byte, dùng để đánh dấu "nhóm các link cùng nối tới một thiết bị đầu cuối". Giá trị này thường lấy từ LACP system ID, hoặc do người vận hành cấu hình thủ công. Khi cả Leaf1 và Leaf2 cùng khai báo chung một ESI cho link nối tới cùng một server, chúng "biết" nhau: "chúng ta đang cùng phục vụ một thiết bị, cần phối hợp."

Single-Active vs Active-Active​

Có hai chế độ vận hành khi multi-home:

  • Single-Active: một leaf đóng vai trò primary (forward traffic), leaf còn lại là standby thuần túy. Đơn giản, không phải lo về loop, nhưng không tận dụng được cả hai đường cùng lúc.
  • Active-Active (RFC gọi chính thức là All-Active, nhưng "active-active" là cách gọi phổ biến trong tài liệu vendor, và cả Junos CLI cũng dùng keyword all-active): cả hai leaf đều forward traffic đồng thời (server dùng LACP/bond gộp hai link vật lý thành một logic). Tận dụng 100% băng thông cả hai đường, và khi một leaf down, traffic chuyển ngay sang leaf còn lại mà không cần chờ gì cả.
Two Multi-Homing ModesSingle-ActiveActive-Active (all-active)Leaf-AforwardingLeaf-Bstandby onlyServerone active linkSimple, but half the bandwidth sits idleLeaf-Cforwarding, DFLeaf-DforwardingServerLACP bondFull bandwidth, but only the DF may flood BUM

Designated Forwarder (DF) — ai được phép flood BUM?​

Active-Active tạo ra một vấn đề mới: nếu BUM traffic cần flood tới server, và cả hai leaf đều forward, server sẽ nhận hai bản sao trùng nhau của cùng một gói. Giải pháp: tại một thời điểm, chỉ định đúng một leaf trong nhóm ESI được phép flood BUM tới server. Leaf đó gọi là Designated Forwarder (DF).

Designated Forwarder Election (Active-Active)Server (LACP bond)ESI=0x0011...Leaf1 — DFUnicast: forward ✓BUM: forwards to the server ✓Leaf2 — non-DFUnicast: forward ✓BUM: does NOT reach the serverIf Leaf1 (the DF) goes down:Leaf2 is elected the new DF and keeps forwarding BUM to the server

Việc bầu DF dựa trên một route riêng: Type 4 (Ethernet Segment Route) mang thông tin về ESI và danh sách leaf đang tham gia, dùng để chạy thuật toán bầu chọn. Thuật toán mặc định trong chuẩn gốc RFC 7432 gọi là "service carving", dựa trên phép chia lấy dư (modulo) giữa số lượng PE tham gia ESI và giá trị VLAN. Cách này bộc lộ hạn chế về hiệu quả khi số lượng PE lớn, hoặc khi cần ưu tiên theo trạng thái attachment circuit. Các thuật toán DF mở rộng và linh hoạt hơn, chẳng hạn HRW (Highest Random Weight), được chuẩn hóa sau này ở RFC 8584.

4. L2 Stretch — Extend VLAN qua nhiều site​

L2 Stretch (còn gọi là L2 Extension hay DCI L2) nghĩa là kéo dài cùng một VLAN qua nhiều site vật lý khác nhau: host ở site A và site B vẫn nằm chung một subnet, chung một broadcast domain, dù về mặt vật lý chúng cách xa nhau qua một kết nối WAN.

Cách EVPN model hóa việc này: DCI link được xem như một Ethernet Segment (ESI), đúng khái niệm vừa được định nghĩa đầy đủ ở Mục 3 phía trên, sau khi đã lướt qua ở Phần 3, Mục 3. Mọi leaf trong cùng một site chia sẻ chung một ESI, để site đối diện biết được "có bao nhiêu đường vào site này".

L2 Stretch: Same VLAN Across Two SitesSite A — ESI=0x0011...Leaf-A1Leaf-A2VM-A10.1.1.10VLAN 100, same subnet 10.1.1.0/24Both leaves send Type-1 Per-EVISite B sees 2 paths into Site ASite B — ESI=0x0033...Leaf-B1Leaf-B2VM-B10.1.1.20DCI (VXLAN, VNI 1000 extended)VM-A and VM-B talk over plain L2 ARP, as if they shared one switch

Type 1 đóng ba vai trò trong L2 Stretch, và cả ba đều là hệ quả trực tiếp của việc "có ESI dùng chung giữa nhiều leaf" mà Phần 3 đã giới thiệu rồi gặp lại ở Mục 3 phía trên:

  1. Aliasing: nếu VM-B gửi cho VM-A, Type 2 chỉ nói "MAC=VM-A qua Leaf-A1", nhưng Type 1 Per-EVI cho biết ESI đó cũng reachable qua Leaf-A2 → Site B có thể load-balance traffic trên cả hai đường DCI.
  2. Fast convergence: nếu Leaf-A1 down, một Type 1 Per-ES withdraw duy nhất báo ngay cho Site B biết "mất đường qua Leaf-A1", chuyển hết traffic sang Leaf-A2 mà không cần chờ MAC aging timeout.
  3. Split horizon: ngăn BUM traffic bị bounce qua lại vô tận giữa hai site, dùng đúng cơ chế Local Bias (so khớp source VTEP IP với danh sách NVE cùng ES) đã giải thích ở Phần 3.

So sánh L2 Stretch với Type-5 DCI​

L2 Stretch (Type 1 + Type 2)DCI qua Type 5
LayerL2 — cùng subnet, cùng VLANL3 — khác subnet, cần routing
Giao tiếpQua ARP, không cần gatewayCần gateway/routing
BUM trafficCó, flood qua DCIKhông có (chỉ routing)
Dùng khiVM migration, ứng dụng phụ thuộc L2Routing liên DC, microservice
Khả năng mở rộngKém hơn (BUM đi qua WAN)Tốt hơn

Nhìn lại chặng đường Phần 1–4, trước khi sang cấu hình thật​

Bốn phần vừa qua, dù đọc riêng lẻ có thể thấy như bốn chủ đề khác nhau, thực chất là một mạch lập luận liền mạch, trong đó mỗi phần chỉ tồn tại để trả lời đúng một câu hỏi mà phần trước để ngỏ:

  • Phần 1 trả lời "vì sao cần EVPN": leaf-spine buộc phải thuần layer 3, nhưng vMotion cần layer 2. EVPN là câu trả lời cho mâu thuẫn đó, bằng cách dùng route (MP-BGP) thay cho flood để "stretch" một VLAN qua hạ tầng layer 3. Phần này cũng dựng xong underlay, overlay và cơ chế policy RD/RT chạy trên chúng.
  • Phần 2 lấp khoảng trống "fabric đó chở cái gì": hai forwarding space, MAC VRF cho bridging trong một VLAN và IP VRF cho routing giữa các VLAN, cùng luồng gói tin Symmetric IRB đi qua từng bước. Đây là chỗ Layer 2 VNI và Layer 3 VNI được định nghĩa.
  • Phần 3 mở khóa câu hỏi "route đó trông như thế nào": 5 loại route type, mỗi loại trả lời một câu hỏi riêng (ai ở đâu, VNI nào có mặt ở VTEP nào, ai đang multi-homed), rồi ráp lại thành một luồng học MAC/IP hoàn chỉnh. Chính luồng đó là cơ chế đứng sau ARP Suppression mà Phần 1 đã hứa hẹn.
  • Phần 4 khép lại mảng khái niệm bằng hai câu hỏi còn sót: định tuyến giữa các VNI khác subnet thế nào (Asymmetric/Symmetric IRB, và cả trường hợp mở rộng ra ngoài fabric qua Type 5/DCI), và một thiết bị vật lý có thể nối tới nhiều leaf cùng lúc ra sao mà không tạo loop hay duplicate traffic (ESI/multi-homing). Cả hai đều là hệ quả trực tiếp của những khái niệm nền tảng (Route Target, VTEP, split-horizon) đã đặt ra từ Phần 1.

Không có khái niệm nào trong bốn phần này đứng được một mình. RT từ Phần 1 quay lại ở khắp Phần 2, Phần 3 và Phần 4; Layer 3 VNI định nghĩa ở Phần 2 là điều kiện để hiểu Symmetric IRB ở Phần 4; ESI được Type 1 dùng ở Phần 3 rồi mới được định nghĩa đầy đủ ở Phần 4; ARP Suppression được Phần 1 nêu tên, phải sang Phần 3 mới giải thích được vì sao nó hoạt động. Vì cách móc nối đó, bốn phần nên được đọc liền mạch hơn là tra cứu rời rạc từng mục khi cần.

Tới đây đã đủ nền tảng khái niệm để đọc một output CLI thật (show route table bgp.evpn.0, show evpn database...) mà không bị choáng ngợp: từng trường trong route đều nhận ra được đang thuộc loại nào trong 5 route type, đang phục vụ MAC VRF hay IP VRF, và vì sao nó tồn tại. Phần 5 đi đúng vào việc đó.

Nguồn tham khảo​

Đính chính/bổ sung kỹ thuật (từ fact-check, không có trong nội dung gốc):

  • Type 5 (IP Prefix Route) được chuẩn hóa ở RFC 9136 (2021) — không nằm trong RFC 7432 gốc như thường bị hiểu nhầm.
  • Asymmetric/Symmetric IRB được định nghĩa chính thức ở RFC 9135 (2021).
  • Thuật toán DF election mặc định ("service carving") nằm trong RFC 7432; các thuật toán mở rộng (bao gồm HRW) được chuẩn hóa ở RFC 8584.
  • GW IP khi dùng làm Overlay Index cần recursive resolution qua Type 2 route; khi không dùng (chế độ advertise direct-nexthop/Pure Type 5) GW IP bắt buộc là 0.0.0.0, forward dựa vào router's MAC extended community — RFC 9136, Juniper — Understanding EVPN Pure Type 5 Routes.
  • Split-horizon cho EVPN-VXLAN dùng cơ chế Local Bias (so khớp source VTEP IP với danh sách NVE cùng ES), không phải nhét ESI vào gói tin như EVPN-MPLS — RFC 8365 §8.3.1.
  • RFC 7432 §3 gọi chế độ multi-homing "cả hai leaf cùng forward" là All-Active Redundancy Mode; "Active-Active" là cách gọi phổ biến theo tài liệu vendor (kể cả Junos CLI keyword all-active) — RFC 7432 §3.

Tiếp theo: Phần 5: Cấu Hình, Kiểm Tra & Xử Lý Sự Cố. Đây là phần đầu tiên có cấu hình thật, trình bày song song trên Junos, Cisco NX-OS, Arista EOS và Huawei VRP, với mục tiêu làm rõ từng dòng lệnh chính là khái niệm nào trong Phần 1 đến Phần 4.